CR 2375: TimeType.to_readable should display microsecond precision. #197
Conversation
Ahmad-Bamba
force-pushed
the
feat/Ahmad-Bamba_2375
branch
from
ec6abcf
to
a5805aa
Compare
There was a problem hiding this comment.
Looks good to me! Thank you!
Could we just force the timespec dt.isoformat(timespec="microseconds") ? Default seems to be auto which falls back to microseconds in our case, but you never know, and it's also easier to read/understand that way.
You're also going to need to format the file for it to pass CI, and add isoformat to https://github.com/fprime-community/fprime-tools/blob/devel/.github/actions/spelling/expect.txt for spelling
|
Feel free to let me know if there is anything else that can be done to improve this |
|
@Ahmad-Bamba could you please also push the timespec="microseconds" change? |
|
Ah, I neglected to actually git add that file. My bad |
Ahmad-Bamba
force-pushed
the
feat/Ahmad-Bamba_2375
branch
from
2d7de7c
to
dbd48ea
Compare
…pe.py with Black. Add isoformat to spellcheck CI"
Ahmad-Bamba
force-pushed
the
feat/Ahmad-Bamba_2375
branch
from
dbd48ea
to
c572884
Compare
|
Should be good. Sorry about that! |
|
@LeStarch would you put a second set of eyes on this ? |
Change Description
This change makes the TimeType.to_readable function use datetime.isoformat to convert the datetime object to a human readable format. In doing so, fprime-gds outputs
channel.logentries with microsecond precision.Rationale
Testing/Review Recommendations
I tested the changes locally by first following the fprime hello world tutorial. Then I installed the local version of fprime-tools, and ran the example project with
fprime-gds. This produced the following output that I've attached below showing no more accuracy loss inchannel.log:Compared with before this change:
Future Work
This seems like too a small change to make a unit test for, but I could think of a good way to design one if requested.